BGP Multicast VPN
Published: 2021-12-26
This post assumes the reader has prior knowledge regarding MPLS L3VPN, LDP and PIM. We will be implementing this on JunOS and IOS-XR.
This type of Multicast VPN used to be called Next Generation MVPN or NG-MVPN because it uses BGP signaling instead of PIM signaling between PEs. Previous generations where called Rosen GRE and Rosen mLDP that relied on PE-to-PE PIM adjacencies to signal the multicast state.
One improvement of BGP over PIM between PEs is that an update is only sent once. With PIM, the PEs have to continually update each other on the current state, causing less scalability.
MVPN terminology
- AD = Auto Discovery
- PMSI = Provider Multicast Service Interface. Can be described as a P2MP tunnel/LSP.
- I-PMSI = Inclusive PMSI, similar to PIM Dense Mode. Tunnel leads to all other PEs.
- S-PMSI = Selective PMSI, similar to PIM Sparse Mode. Tunnel leads to a select group of receiver PEs.
Inclusive vs Selective Tunnels
Multicast is a constant battle of bandwidth efficiency and signaling efficiency, you can't have both at the same time. Selective tunnels (S,G) and (*,G) are most efficient in terms of bandwidth since they reach only reach receivers that specifically requested the traffic. Inclusive tunnels (*,*) have very little signaling but often waste bandwidth resources.
BGP MVPN defaults to inclusive tunnels and sends the multicast flows to all MVPN PE neighbors in the L3VPN. Once the bandwidth of a multicast flow exceeds a set threshold, the flow can be moved to a selective tunnel that is signaled separately, allowing specific receiver PEs to join.
BGP MVPN Route Types
The job of BGP MVPN is advertising the multicast routes inside a L3VPN. To get this done, a number of different route types are used. We will focus on Type 1 in this chapter, but each is briefly described here:
-
Intra-AS I-PMSI Auto Discovery
This is equivalent to a PIM Hello packet. A PE will advertise a Type 1 route to let all other PEs in the L3VPN know that it is available send or receive multicast traffic, essentially joining the inclusive tunnel for this VPN.
-
Inter-AS I-PMSI Auto Discovery
Same as type 1, but between ASes. We will not cover this here.
-
S-PMSI Auto Discovery
This route is advertised by the Sender PE, allowing Receiver PEs to choose if they want to receive this particular multicast traffic or not, hence the keyword selective.
-
Leaf Auto Discovery
This route is advertised by a Receiver PE to the Sender PE of a selective multicast flow when the transport is RSVP, allowing the PE to receive a selective multicast flow. This route type is not necessary when using mLDP as the multicast transport.
-
Source Active Auto Discovery
Not covered here
-
C-Multicast Source Tree Join
Not covered here
-
C-Multiast Shared Tree Join
This route is advertised by a Receiving PE when receiving a downstream PIM Join message from a CE; the route is basically a Join message for a specific (S,G) multicast flow and is targeted to a specific Sender PE. The route does not include any information about who the Receiver PE is. This route is necessary in case the Sender PE wants to send the multicast on an S-PMSI, that way the Sender PE know that alteast one reciever PE is interested in receiving this flow.
For this reason, low bandwidth multicast flows are sent as Inclusive by default. Once the flow bandwidth pass a certain threshold value, the traffic is instead moved to a Selective tunnel.
LDP Transport
This topology uses LDP to MPLS encapsulate the unicast L3VPN traffic and mLDP to MPLS encapsulate the multicast L3VPN traffic. This allows traffic VPN traffic between PEs to travel across the core without the P-nodes having to examine the IP header.
Unicast LDP
Unicast LDP builds Multi-point-to-Point(MP2P) LSPs for each prefix, meaning the same label is advertised to all neighbors. For example, P2 received the loopback prefix 1.1.1.1/32 from PE1. P2 forwards this route to PE3 and P5 with label 111 essentially saying; use this label if you want me to forward traffic to PE1. It doesn't matter if the traffic is received from PE3 or P5, label 111 sends the traffic to PE1. In other words, the MP2P LSP is signaled from the Receiver PE to all Sender PEs.
Multicast LDP (mLDP)
To allow the multicast traffic to flow MPLS-encapsulated across the core network we enable Multicast LDP, mLDP for short. A multicast mLDP LSP is Point-to-Multi-point (P2MP), so the exact opposite of unicast LDP. The P2MP LSP is signaled from every Receiver towards the Source PE.
Example Topology
Topology is as shown below. All core links have a metric of 1 except for PE-PE links that have a metric of 10. P2 is also the RR. PC111 is the source of the (10.0.11.111, 232.1.1.1) multicast flow that the other PCs want to receive. All CEs belong to the same VRF-A L3VPN.
mLDP signaling in our example topology
This section looks at how mLDP is used to signal a multicast path from each Receiver PE towards PE1, the Sender PE.
PE1 advertises Type 1 route:
Let's look at an example using the BGP Multicast VPN topology below. Let's look at the BGP route advertised by PE1 when it joins the VRF-A VPN. With this route, PE1 tells the other PE routers in the VPN that it may want to send or receive multicast traffic in the future.
Frame 12: 188 bytes on wire (1504 bits)
Internet Protocol Version 4, Src: 1.1.1.1, Dst: 2.2.2.2
Border Gateway Protocol - UPDATE Message
Path Attribute - MP_REACH_NLRI
(AFI): IPv4 (1), (SAFI): MCAST-VPN (5)
Intra-AS I-PMSI A-D route (12 bytes)
Route Distinguisher: 65000:1
Originating Router: 1.1.1.1
Path Attribute - PMSI_TUNNEL_ATTRIBUTE
Type Code: PMSI_TUNNEL_ATTRIBUTE (22)
Tunnel Type: mLDP P2MP LSP (2)
Tunnel ID: Type: P2MP root node: 1.1.1.1 Id: 16777219
The output show the route as a Type 1 Intra-AS I-PMSI A-D. PE1 has assigned the tunnel ID 16777219 and the multicast traffic will be transported in a mLDP LSP. As soon as the other PEs receive this route, they immediately begin signaling a P2MP mLDP LSP towards 1.1.1.1, as shown below.
Receiver PE LDP signaling towards PE1:
The wireshark output below show the LDP signaling along the path from PE4 and PE6 towards PE1. As the output will show; every message contains the same tunnel ID advertised by PE1, but each router along the path generates its own local label.
Internet Protocol Version 4, Src: 6.6.6.6, Dst: 5.5.5.5
Label Distribution Protocol
Label Mapping Message
FEC
FEC Element Type: P2MP
Root Node Address: 1.1.1.1
Opaque Value: 16777219
Generic Label: 24011
Internet Protocol Version 4, Src: 4.4.4.4, Dst: 5.5.5.5
Label Distribution Protocol
Label Mapping Message
FEC
FEC Element Type: P2MP
Root Node Address: 1.1.1.1
Opaque Value: 16777219
Generic Label: 24000
Internet Protocol Version 4, Src: 5.5.5.5 Dst: 2.2.2.2
Label Distribution Protocol
Label Mapping Message
FEC
FEC Element Type: P2MP (6)
Root Node Address: 1.1.1.1
Opaque Value: 16777219
Generic Label: 24010
Internet Protocol Version 4, Src: 2.2.2.2 Dst: 1.1.1.1
Label Distribution Protocol
Label Mapping Message
FEC
FEC Element Type: P2MP (6)
Root Node Address: 1.1.1.1
Opaque Value: 16777219
Generic Label: 300288
PE3 and PE4 joining the multicast tree:
PE3 and PE4 has not yet sent their mLDP messages. Let's say PE4 send its mLDP message to P5 now. The tunnel ID is the same, 16777219, and PE4 chooses to advertise label 24000 to P5.
When P5 receive the message from PE4, it realizes the tunnel ID is the same as the one signaled by PE6, so no further mLDP messages are sent upstream towards PE1. Instead P5 adds its interface towards PE4 to the list of outgoing interfaces, becoming a brancing point in the multicast tree and replicates the packet, sending one copy to PE6 and one to PE4. This is the MPLS forwarding output on P5:
RP/0/0/CPU0:P5#show mpls forwarding labels 24010
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24010 24000 mLDP/IR: 0x0000c Gi0/0/0/4 10.4.5.4 0
24011 mLDP/IR: 0x0000c Gi0/0/0/6 10.5.6.6 0
The same thing happens on P2 when it receives the mLDP message from PE3. The interface towards PE3 is added to the outgoing interface list, no additional signaling towards PE1 is required.
The label path in action:
PC111 start generating multicast traffic that is sent to CE11 which forwards it to PE1. PE1 sends the trafic out on tunnel 16777219 and is forwarded to PE6 like this:
label 300228 label 24010 label 24011
PE1 -------------> P2 -------------------> P5 ------------> PE6
| label 300240 | label 24000
+---------------> PE3 +--------------> PE4
Finally PE6 receives the traffic and forwards it to PC133 via CE33.
Configuration
This is the configuration used in this lab.
ip multicast-routing
interface FastEthernet0/0
ip address 10.1.11.11 255.255.255.0
ip pim sparse-mode
interface FastEthernet1/0
ip address 10.0.11.1 255.255.255.0
ip pim sparse-mode
ip igmp version 3
router bgp 65001
bgp log-neighbor-changes
redistribute connected
neighbor 10.1.11.1 remote-as 65000
no ip pim autorp
ip pim ssm default
set security forwarding-options family mpls mode packet-based
set interfaces ge-0/0/0 unit 0 family inet address 10.1.11.1/24
set interfaces ge-0/0/2 unit 0 family inet address 10.1.2.1/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/4 unit 0 family inet address 10.1.4.1/24
set interfaces ge-0/0/4 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set routing-instances VRF-A instance-type vrf
set routing-instances VRF-A protocols bgp group CE type external
set routing-instances VRF-A protocols bgp group CE peer-as 65001
set routing-instances VRF-A protocols bgp group CE as-override
set routing-instances VRF-A protocols bgp group CE neighbor 10.1.11.11
set routing-instances VRF-A protocols mvpn
set routing-instances VRF-A protocols pim interface ge-0/0/0.0
set routing-instances VRF-A interface ge-0/0/0.0
set routing-instances VRF-A route-distinguisher 65000:1
set routing-instances VRF-A vrf-target target:65000:1
set routing-instances VRF-A vrf-table-label
set routing-instances VRF-A provider-tunnel ldp-p2mp
set routing-instances VRF-A provider-tunnel selective group 232.0.0.0/8 source 0.0.0.0/0 ldp-p2mp
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 ldp-synchronization
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 metric 10
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 ldp-synchronization
set protocols bgp group PE type internal
set protocols bgp group PE local-address 1.1.1.1
set protocols bgp group PE family inet-vpn unicast
set protocols bgp group PE family inet-mvpn signaling
set protocols bgp group PE peer-as 65000
set protocols bgp group PE mvpn-iana-rt-import
set protocols bgp group PE neighbor 3.3.3.3
set protocols bgp group PE neighbor 4.4.4.4
set protocols bgp group PE neighbor 6.6.6.6
set protocols igmp interface ge-0/0/0.0 version 3
set protocols ldp interface ge-0/0/2.0
set protocols ldp interface ge-0/0/4.0
set protocols ldp p2mp
set protocols mpls interface ge-0/0/2.0
set protocols mpls interface ge-0/0/4.0
set routing-options autonomous-system 65000
hostname PE4
domain lookup disable
vrf VRF-A
address-family ipv4 unicast
import route-target
65000:1
export route-target
65000:1
line console
width 128
length 0
!
interface Loopback0
ipv4 address 4.4.4.4 255.255.255.255
!
interface MgmtEth0/0/CPU0/0
shutdown
!
interface GigabitEthernet0/0/0/0
vrf VRF-A
ipv4 address 10.4.44.4 255.255.255.0
!
interface GigabitEthernet0/0/0/1
ipv4 address 10.1.4.4 255.255.255.0
!
interface GigabitEthernet0/0/0/2
shutdown
!
interface GigabitEthernet0/0/0/3
shutdown
!
interface GigabitEthernet0/0/0/4
shutdown
!
interface GigabitEthernet0/0/0/5
ipv4 address 10.4.5.4 255.255.255.0
!
route-policy MLDP
set core-tree mldp-default
end-policy
!
router ospf 1
log adjacency changes
mpls ldp sync
mpls ldp auto-config
address-family ipv4
area 0
interface Loopback0
passive enable
!
interface GigabitEthernet0/0/0/1
cost 10
network point-to-point
!
interface GigabitEthernet0/0/0/5
network point-to-point
!
!
!
router bgp 65000
bgp router-id 4.4.4.4
address-family vpnv4 unicast
!
address-family ipv4 mvpn
!
neighbor-group PE
remote-as 65000
update-source Loopback0
address-family vpnv4 unicast
!
address-family ipv4 mvpn
!
!
neighbor 1.1.1.1
use neighbor-group PE
!
neighbor 3.3.3.3
use neighbor-group PE
!
neighbor 6.6.6.6
use neighbor-group PE
!
vrf VRF-A
rd 65000:1
bgp unsafe-ebgp-policy
address-family ipv4 unicast
redistribute connected
!
address-family ipv4 mvpn
!
neighbor 10.4.44.44
remote-as 65001
address-family ipv4 unicast
as-override
!
!
!
!
mpls ldp
mldp
!
interface GigabitEthernet0/0/0/1
!
interface GigabitEthernet0/0/0/5
!
!
multicast-routing
address-family ipv4
interface Loopback0
enable
!
mdt source Loopback0
mdt mldp in-band-signaling ipv4
!
vrf VRF-A
address-family ipv4
interface GigabitEthernet0/0/0/0
enable
!
bgp auto-discovery mldp
!
mdt default mldp p2mp
!
!
!
router pim
vrf VRF-A
address-family ipv4
rpf topology route-policy MLDP
mdt c-multicast-routing bgp
!
interface GigabitEthernet0/0/0/0
enable
!
!
!
!
end